Remove async std dependency #103
Conversation
6718f1c to
fdc7aed
Compare
|
can't seem to get this working with rust 1.63.0 when i run I get: |
| #[cfg(feature = "async-std")] | ||
| pub use async_std::task::sleep; | ||
|
|
||
| #[cfg(not(any(feature = "tokio", feature = "async-std")))] |
There was a problem hiding this comment.
Mhh, in general features should be additive, so I'm not sure we want to add a layer of non-additive features here. Also the choice between tokio and async-std is pretty limited, and given the former is the defacto standard by now we may as well drop async-std entirely, IMO. I also think we should introduce a Sleeper trait an provide a tokio-based default implementation, allowing users to implement it any other way too, instead of only allowing these two choices.
E.g., I think WASM users won't be able to use tokio, and it looks like they won't be able to use async-std either (cf. async-rs/async-std#220). So, this change would really won't leave a way for them to keep using the esplora client, IIUC. (Although that issue is now kind of pre-existing since the async-std dependency has been introduced.
There was a problem hiding this comment.
I’m good with only supporting Tokio.
I think WASM users would just use the blocking client and skip the async features all together?
There was a problem hiding this comment.
Adding tokio or async-std would only be needed is the async features is also enabled.
There was a problem hiding this comment.
I think WASM users would just use the blocking client and skip the async features all together?
I don't think they can use the blocking client. Usually WASM is async-everything but it's driven by WASM's own executor. So AFAIK we need to allow for a way to bring your own runtime to let them continue to use the rust-esplora-client crate.
There was a problem hiding this comment.
Interesting, i didn't know that, i've only used WASM for any network calls just number crunching. Does their runtime have a task too? Could we use that with features and conditional compilation?
There was a problem hiding this comment.
Interesting, i didn't know that, i've only used WASM for any network calls just number crunching. Does their runtime have a task too?
Mhh, I'm not sure, I think most of them are just using wasm_bindgen and did so successfully previously with rust-esplora-client and projects based on it. AFAIK just using async reqwest works decently.
Could we use that with features and conditional compilation?
I really don't think we should go there and introduce even more assumptions on how the user wants to use the library, which is essentially a a bunch of types, i.e., a thin wrapper around an HTTP client. I think the API of this crate should be flexible but overall kept very very simple. Tbh, I don't see a reason why this crate should have much more than a single dependency on serde_json, especially when we end up going the #97 direction.
There was a problem hiding this comment.
I think that makes sense, as long as we keep the logic for retires and that kinda stuff.
There was a problem hiding this comment.
I agree with tnull's comments, I think it's pretty straightforward to have and use a Sleeper trait, using the tokio (already existing one) as the default batteries included implementation, alongside allowing the user to implement their own, for example, gloo-timers for WASM.
|
@tnull @oleonardolima using a trait instead now |
f6695b3 to
35b6377
Compare
Awesome! I'd still not bring |
|
@oleonardolima I could get rid of it, but its an optional dep and I thought it would be nice keep in there because if it's zero cost if you don't use it and if you are using Builder::new(...)Instead of struct AsyncStd;
impl Runtime for AsyncStd {...}
Builder::<AsyncStd>::new_custom_runtime(....)If you don't think its worth it tho, I'll get rid of it. |
Also +1 for dropping |
|
Alright guys you convinced me, I never use |
oleonardolima
left a comment
There was a problem hiding this comment.
I guess there are some old commits that could be dropped, or everything squashed into a single one.
I'm still unsure about the appropriate feature structure, looking forward to have other's opinions about it.
| blocking-https-bundled = ["blocking", "minreq/https-bundled"] | ||
| async = ["async-std", "reqwest", "reqwest/socks"] | ||
|
|
||
| tokio = ["dep:tokio", "async"] |
There was a problem hiding this comment.
I wonder if we do need to have tokio as a separate feature, maybe we can have as part of the async one, as we did for async-std, still unsure about it. WDYT ?
There was a problem hiding this comment.
I think it makes sense, its a default feature, but if a user wanted to use a different async runtime, but still wanted to use reqwest, without tokio like in WASM, they could disable default features and add wasm and async, features.
I think it gives more flexibilty without adding annoyance since its a default feature.
There was a problem hiding this comment.
Yes, I was afraid of bringing some other unwanted dependencies through tokio, but reqwest already uses it with features net and time, so it should be unified, looks fine.
oleonardolima
left a comment
There was a problem hiding this comment.
It seems to be failing regarding using only blocking feature, I left some comments/suggestions.
6c26120 to
d248d90
Compare
Pull Request Test Coverage Report for Build 11880146166Details
💛 - Coveralls |
|
Im not sure, but I would use refactor(retry)!: ..., as I consider it a breaking change on how the feature works. |
01fd667 to
7cae4b8
Compare
|
I think we will need #110 to get this to run in CI. |
|
@praveenperera Can you rebase? |
7cae4b8 to
9963f27
Compare
|
@ValuedMammal done |
|
Code review ACK It could use some documentation improvements, but that can be done in a follow up PR. I tested upgrading |
|
I can confirm that this patch compiles and works in our downstream code after reducing the tokio requirement from 1.38->1.36. |
| #[cfg(feature = "async")] | ||
| use r#async::Sleeper; |
There was a problem hiding this comment.
nit: we wouldn't need this other import if we use the full r#async::Sleeper below instead. Could be addressed in a future PR.
6346012 to
a5aa7f4
Compare
a5aa7f4 to
27c4125
Compare
oleonardolima
left a comment
There was a problem hiding this comment.
tACK 27c4125
Thanks for working on this one!
It looks pretty straightforward right now, and I was able to run it as examples with custom async-std and gloo-timers, instead of the default tokio runtime while only relying on the async-https feature.
90fd1a2 docs(esplora): update README.md (valued mammal) f0e6395 deps(esplora): bump `esplora-client` to 0.11.0 (valued mammal) Pull request description: Update `bdk_esplora` to depend on esplora-client 0.11.0 ### Notes to the reviewers bitcoindevkit/rust-esplora-client#103 added a generic type parameter to `AsyncClient` representing a user-defined `Sleeper` and that change is reflected here in order to call the underlying API methods. We also add a new build feature "tokio" that enables the corresponding feature in rust-esplora-client. closes #1742 ### Changelog notice `bdk_esplora`: Bump `esplora-client` to 0.11.0 ### Checklists #### All Submissions: * [x] I've signed all my commits * [x] I followed the [contribution guidelines](https://github.com/bitcoindevkit/bdk/blob/master/CONTRIBUTING.md) * [x] I ran `cargo fmt` and `cargo clippy` before committing * [x] This pull request breaks the existing API * [x] I'm linking the issue being fixed by this PR ACKs for top commit: notmandatory: tACK 90fd1a2 oleonardolima: ACK 90fd1a2 Tree-SHA512: 98d529d3bb0dbbf4bbafeea7d30ec5e5816ac9800ba2cb7981fc6189b4b02774956c3ddbb74bf0b3e6e22798bfced36508263e4e89c248b7a6240c5c7109107b
27c41258cfa10b5a88598364a6605b8502f79a8e refactor(async)!: remove async-std dependency, allow custom runtime (Praveen Perera)
Pull request description:
Closes: #102
ACKs for top commit:
ValuedMammal:
reACK 27c41258cfa10b5a88598364a6605b8502f79a8e
oleonardolima:
tACK 27c41258cfa10b5a88598364a6605b8502f79a8e
Tree-SHA512: c25e9ca65441b2a53c3eabe50426c4f223566e024704db36929797c86be48899df7e7a7de75231cab8c1c70ac87d7a8bd029cdc466b8b3e47122db4ee963d393
Closes: #102